1. Field of the Invention
This invention relates generally to the field of computing technology and more particularly concerns the reducing of congestion in internet protocol storage.
2. Description of the Related Art
Typically, in the computing industry, data may be transferred over several different types of networks such as the Internet, Large Area Networks (LAN), Wide Area Networks (WAN), Storage Area Networks (SAN), etc. Typically, data transferred over these types of networks may involve utilization of data transfer protocols such as, for example, transmission control protocol (TCP) and an internet protocol (IP). Quite often, the protocols representative of the types of transfer protocols used over the Internet is commonly known as TCP/IP.
Through use of the TCP, data that is sent over a network is broken up into little pieces for transmission and reassembled once the data reaches its destination. Data may be sent in the form such as, for example, data packets, etc. Depending on the interface used, the TCP may break down data into a variety of data packet sizes such as 128 byte packets. The TCP includes its own information which allows the data to be reattached in the correct order as well as resending any data that happens to get “dropped” (data that is lost due to various reasons such as congestion over the network). IP routes the data packaged by the TCP to a destination such as a device within a network.
TCP/IP protocols may also be used to direct data flow and transfer in data storage systems over a network. For example, small computer system interface (SCSI) may be used over TCP/IP to store data over a network onto a SCSI peripheral device for storage. Therefore, TCP and IP are often used over a network to control data transfer to and from a storage device. Typically TCP utilizes a form of congestion avoidance and control in an attempt to minimize congestion in bulk data movement. Unfortunately, TCP's attempt to minimize congestion while maintaining an optimal data transfer rate is not very successful.
Quite often, data movement by TCP results in increased delay of data transfer due to congestion and lower use of wire bandwidth than is capable by the transmission media. In one example, TCP utilizes a combination of a slow start mechanism and a slow start threshold register (SSTHRESH) in an attempt to unsuccessfully optimize data throughput while controlling data transfer congestion.
A slow start mechanism initially sends one Maximum Transport Unit (MTU) of data when a new connection is started or when an old connection is restarted after being idle. As each data packet is acknowledged, the send limit is increased so the sending rate of data increases exponentially, 1, 2, 4, 8, etc. Generally, the maximum size of data which may be transported is the lesser of 64 kilobytes or a user set amount. A congestion window (CWND) is the register that enforces this byte limit. Unfortunately, in this example, after an initial slow step up in transmission rate, the slow start mechanism quickly hits the capacity limit of a network because of the exponential increase in the data transported. For example, if a network can only handle 16 packets at a time, the limit would be reached after only 5 packet round trip times (RTT). A round trip time is the time it takes for a packet to be sent from a sending host until the time the sending host receives an acknowledgement for the packet. SSTHRESH works to superimpose a cap on a slow start mechanism by limiting the increase in the CWND from an exponential rate to one packet per round trip time once the SSTHRESH value is exceeded.
TCP combines slow start and SSTHRESH by reducing CWND to 1 MTU, entering slow start when congestion is detected, and setting the SSTHRESH to 50% of the total number of packets in transport at the time the congestion is detected. Consequently, when congestion is detected, packet injection increases rapidly to 50% of the rate prior to congestion detection. The data transfer rate is reduced by a multiplicative fashion for fairness reasons so sending hosts taking up more of the throughput capacity is penalized more than sending hosts taking up less of the throughput capacity. For further details regarding the fairness concept in TCP data transfer, reference may be made to an article published in 1989 entitled, “Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Complex Networks” written by Dah-Ming Chiu and Raj Jain. This article is hereby incorporated by reference. Because slow start is utilized and CWND is reset to 1 MTU, the data transfer rate drops severely after congestion is detected even if congestion is not severe. Accordingly, this method does not allow the use of the full capacity of a transmission media or network while at the same time keeping congestion at a minimum.
In another example, TCP uses packet marking (described below) to determine congestion over a network and attempts to respond accordingly. Problems may arise when multiple hosts attempt to send data over one switch or router. In this circumstance, the switch or line between two switches may become overloaded and congestion may occur resulting in dropped packets.
One common way of detecting congestion over a network is by the use of a random early detection (RED) algorithm which finds potential congestion in the network and attempts to signal the congestion back to sending hosts. The algorithm signals congestion to the sending hosts before the input buffers of a switch are actually filled to slow down data transmission and leaves enough room in the buffers to accommodate a burst of packets without loss. Once congestion is detected by the sending host, it generally reduces its send window (the amount of packets sent during a certain period of time) by a half. Typically, the method used to signal congestion under this method is to “drop” data packets. This means that certain random data packets received by a switch are not sent. When data packets are dropped, the host sender does not receive ACKs (positive acknowledgement packets) indicating that the data packets were received. The dropping of packets forces a host sender to resend the packets that were dropped. The RED algorithm also calculates a running average of queue depth and signals congestion with increasing frequency as the average queue depth increases above a threshold. Therefore, possible congestion is detected before congestion can actually occur. As is obvious, this is a rather severe form of congestion reduction because data packets may be dropped even though congestion has not yet occurred.
Another slightly more gentle way to detect and reduce congestion is by combining the use of a RED algorithm and a data marking system. FIG. 1A illustrates a simplified multiple TCP host data transfer system 100 using the RED algorithm and the data marking system. In this example, a sending host-1 102 and a sending host-2 104 are both connected to a switch-1 106. The switch-1 106 is also connected to a switch-2 108 by a line 107. The switch-2 108 is then connected to a receiving host-1 110 and a receiving host-2 112.
In one example of a data transfer, the sending host-1 102 and the sending host-2 104 may both send data to either the receiving host-1 110 or the receiving host-2 112. In this circumstance, data from both sending hosts 102 and 104 will be sent to the switch-1 106. When the data from the sending hosts 102 and 104 are received, the switch-1 attempts to send data packets from both the sending hosts 102 and 104 to switch-2. Far too often, the connection, such as line 107, between the switches 106 and 108 may not support a transmission rate of data which would enable transportation of data from both the sending hosts 102 and 104. Therefore, congestion may occur (as indicated by a RED algorithm described above) at the switch-1 106 and a buffer of the switch-1 106 may overflow if congestion continues. When congestion occurs, the switch-1 106 marks the packet of data that induced the congestion. The switch-2 108 receives the marked data and sends it on to the receiving host-1 110. When the switch-2 108 receives the marked data, it sends a marked ACK back to the sending host-1 102. When this happens the sending host-1 reads the marked ACK and determines that congestion occurred.
When the sending host-1 102 determines that congestion has occurred, the number of packets sent during a round trip time is calculated. In this example, the round trip time (RTT) is the amount of time it takes for the marked ACK to be received by the sending host-1 102 after the data packet was initially sent. Oftentimes, in present TCP congestion reducing protocols, the sending host-1 102 decreases the packets per round trip time by half so that it will be assured that congestion does not take place and fairness factors are taken into account. Unfortunately, this method cuts the packets per RTT in half even when a marked ACK indicating one marked data packet is received (indicating light congestion), and consequently does not differentiate between heavy and light congestion. Therefore, the true congestion level of the network is not gauged. As a result, inefficiencies may be created in the data transmission system because the packets per RTT is cut in half in cases of severe congestion and also in cases of light congestion. Consequently, a severe data transmission reduction occurs when only a minimal correction is required.
FIG. 1B shows a graph illustrating a prior art method of packet marking congestion reduction. The graph depicts the relationships between packets sent per round trip time versus time. In this graph, the packets per round trip time is increased as long as there is no data congestion. In one example, data congestion occurs at peak 114 which is 16 packets per RTT. In this example, the packets per RTT of 16 is the maximum data transmission available. At that point, the sending host-1 102 decreases the packets per RTT by half to 8 as indicated by valley 116. As data transmission occurs and there is no congestion, the packets per RTT increases until peak 118 when congestion is detected by the sending host-1 102 where the packets per RTT is 12. When congestion is detected, the sending host-1 102 again decreases the packets per RTT by half to 6 as indicated by valley 120. When congestion is not detected, the packets per RTT is increased to 12 as shown by peak 122 where once again congestion is detected and the send window of packets per RTT is decreased by a half. As can be seen, with the severe peaks and valleys of data transmission rate, the effective transmission rate is not very high compared to the maximum transmission rate of 16 packets per RTT. In effect, the space above the curve depicted in FIG. 1B shows the unused transmission capacity by the present TCP. This “sawtooth” type curve shows the inefficiencies of the present forms of data congestion control. The present methods of congestion control therefore do a poor job of taking full advantage of the transmission capability of the transmission media used. Regrettably, the peak and average data transfer rate in these prior art systems are substantially less than the capabilities allowed within a network or most any data transfer system.
In view of the foregoing, what is needed is a new and improved methodology for reducing congestion during data transfer and IP storage. Such an approach would take advantage of the full data transfer capabilities in the transmission media, and take into account the actual amount of congestion in the network in the congestion reduction protocol.